home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1537.txt < prev    next >
Text File  |  1994-08-01  |  20KB  |  508 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        P. Beertema
  8. Request for Comments: 1537                                           CWI
  9. Category: Informational                                     October 1993
  10.  
  11.  
  12.                Common DNS Data File Configuration Errors
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  It does
  17.    not specify an Internet standard.  Distribution of this memo is
  18.    unlimited.
  19.  
  20. Abstract
  21.  
  22.    This memo describes errors often found in DNS data files. It points
  23.    out common mistakes system administrators tend to make and why they
  24.    often go unnoticed for long periods of time.
  25.  
  26. Introduction
  27.  
  28.    Due to the lack of extensive documentation and automated tools, DNS
  29.    zone files have mostly been configured by system administrators, by
  30.    hand. Some of the rules for writing the data files are rather subtle
  31.    and a few common mistakes are seen in domains worldwide.
  32.  
  33.    This document is an attempt to list "surprises" that administrators
  34.    might find hidden in their zone files. It describes the symptoms of
  35.    the malady and prescribes medicine to cure that. It also gives some
  36.    general recommendations and advice on specific nameserver and zone
  37.    file issues and on the (proper) use of the Domain Name System.
  38.  
  39. 1. SOA records
  40.  
  41.    A problem I've found in quite some nameservers is that the various
  42.    timers have been set (far) too low. Especially for top level domain
  43.    nameservers this causes unnecessary traffic over international and
  44.    intercontinental links.
  45.  
  46.    Unfortunately the examples given in the BIND manual, in RFC's and in
  47.    some expert documents give those very short timer values, and that's
  48.    most likely what people have modeled their SOA records after.
  49.  
  50.    First of all a short explanation of the timers used in the SOA
  51.    record:
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Beertema                                                        [Page 1]
  59.  
  60. RFC 1537       Common DNS Data File Configuration Errors    October 1993
  61.  
  62.  
  63.         - Refresh: The SOA record of the primary server is checked
  64.                    every "refresh" time by the secondary servers;
  65.                    if it has changed, a zone transfer is done.
  66.  
  67.         - Retry: If a secondary server cannot reach the primary
  68.                  server, it tries it again every "retry" time.
  69.  
  70.         - Expire: If for "expire" time the primary server cannot
  71.                   be reached, all information about the zone is
  72.                   invalidated on the secondary servers (i.e., they
  73.                   are no longer authoritative for that zone).
  74.  
  75.         - Minimum TTL: The default TTL value for all records in the
  76.                        zone file; a different TTL value may be given
  77.                        explicitly in a record when necessary.
  78.                        (This timer is named "Minimum", and that's
  79.                        what it's function should be according to
  80.                        STD 13, RFC 1035, but most (all?)
  81.                        implementations take it as the default value
  82.                        exported with records without an explicit TTL
  83.                        value).
  84.  
  85.    For top level domain servers I would recommend the following values:
  86.  
  87.           86400 ; Refresh     24 hours
  88.            7200 ; Retry        2 hours
  89.         2592000 ; Expire      30 days
  90.          345600 ; Minimum TTL  4 days
  91.  
  92.    For other servers I would suggest:
  93.  
  94.           28800 ; Refresh     8 hours
  95.            7200 ; Retry       2 hours
  96.          604800 ; Expire      7 days
  97.           86400 ; Minimum TTL 1 day
  98.  
  99.    but here the frequency of changes, the required speed of propagation,
  100.    the reachability of the primary server etc. play a role in optimizing
  101.    the timer values.
  102.  
  103. 2. Glue records
  104.  
  105.    Quite often, people put unnecessary glue (A) records in their zone
  106.    files. Even worse is that I've even seen *wrong* glue records for an
  107.    external host in a primary zone file! Glue records need only be in a
  108.    zone file if the server host is within the zone and there is no A
  109.    record for that host elsewhere in the zone file.
  110.  
  111.  
  112.  
  113.  
  114. Beertema                                                        [Page 2]
  115.  
  116. RFC 1537       Common DNS Data File Configuration Errors    October 1993
  117.  
  118.  
  119.    Old BIND versions ("native" 4.8.3 and older versions) showed the
  120.    problem that wrong glue records could enter secondary servers in a
  121.    zone transfer.
  122.  
  123. 3. "Secondary server surprise"
  124.  
  125.    I've seen it happen on various occasions that hosts got bombarded by
  126.    nameserver requests without knowing why. On investigation it turned
  127.    out then that such a host was supposed to (i.e., the information was
  128.    in the root servers) run secondary for some domain (or reverse (in-
  129.    addr.arpa)) domain, without that host's nameserver manager having
  130.    been asked or even been told so!
  131.  
  132.    Newer BIND versions (4.9 and later) solved this problem.  At the same
  133.    time though the fix has the disadvantage that it's far less easy to
  134.    spot this problem.
  135.  
  136.    Practice has shown that most domain registrars accept registrations
  137.    of nameservers without checking if primary (!) and secondary servers
  138.    have been set up, informed, or even asked.  It should also be noted
  139.    that a combination of long-lasting unreachability of primary
  140.    nameservers, (therefore) expiration of zone information, plus static
  141.    IP routing, can lead to massive network traffic that can fill up
  142.    lines completely.
  143.  
  144. 4. "MX records surprise"
  145.  
  146.    In a sense similar to point 3. Sometimes nameserver managers enter MX
  147.    records in their zone files that point to external hosts, without
  148.    first asking or even informing the systems managers of those external
  149.    hosts.  This has to be fought out between the nameserver manager and
  150.    the systems managers involved. Only as a last resort, if really
  151.    nothing helps to get the offending records removed, can the systems
  152.    manager turn to the naming authority of the domain above the
  153.    offending domain to get the problem sorted out.
  154.  
  155. 5. "Name extension surprise"
  156.  
  157.    Sometimes one encounters weird names, which appear to be an external
  158.    name extended with a local domain. This is caused by forgetting to
  159.    terminate a name with a dot: names in zone files that don't end with
  160.    a dot are always expanded with the name of the current zone (the
  161.    domain that the zone file stands for or the last $ORIGIN).
  162.  
  163.    Example: zone file for foo.xx:
  164.  
  165.    pqr          MX 100  relay.yy.
  166.    xyz          MX 100  relay.yy           (no trailing dot!)
  167.  
  168.  
  169.  
  170. Beertema                                                        [Page 3]
  171.  
  172. RFC 1537       Common DNS Data File Configuration Errors    October 1993
  173.  
  174.  
  175.    When fully written out this stands for:
  176.  
  177.       pqr.foo.xx.  MX 100  relay.yy.
  178.       xyz.foo.xx.  MX 100  relay.yy.foo.xx.   (name extension!)
  179.  
  180. 6. Missing secondary servers
  181.  
  182.    It is required that there be a least 2 nameservers for a domain. For
  183.    obvious reasons the nameservers for top level domains need to be very
  184.    well reachable from all over the Internet. This implies that there
  185.    must be more than just 2 of them; besides, most of the (secondary)
  186.    servers should be placed at "strategic" locations, e.g., close to a
  187.    point where international and/or intercontinental lines come
  188.    together.  To keep things manageable, there shouldn't be too many
  189.    servers for a domain either.
  190.  
  191.    Important aspects in selecting the location of primary and secondary
  192.    servers are reliability (network, host) and expedient contacts: in
  193.    case of problems, changes/fixes must be carried out quickly.  It
  194.    should be considered logical that primary servers for European top
  195.    level domains should run on a host in Europe, preferably (if
  196.    possible) in the country itself. For each top level domain there
  197.    should be 2 secondary servers in Europe and 2 in the USA, but there
  198.    may of course be more on either side.  An excessive number of
  199.    nameservers is not a good idea though; a recommended maximum is 7
  200.    nameservers.  In Europe, EUnet has offered to run secondary server
  201.    for each European top level domain.
  202.  
  203. 7. Wildcard MX records
  204.  
  205.    Wildcard MX records should be avoided where possible. They often
  206.    cause confusion and errors: especially beginning nameserver managers
  207.    tend to overlook the fact that a host/domain listed with ANY type of
  208.    record in a zone file is NOT covered by an overall wildcard MX record
  209.    in that zone; this goes not only for simple domain/host names, but
  210.    also for names that cover one or more domains. Take the following
  211.    example in zone foo.bar:
  212.  
  213.          *            MX 100  mailhost
  214.          pqr          MX 100  mailhost
  215.          abc.def      MX 100  mailhost
  216.  
  217.    This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid
  218.    domains, but the wildcard MX record covers NONE of them, nor anything
  219.    below them.  To cover everything by MX records, the required entries
  220.    are:
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Beertema                                                        [Page 4]
  227.  
  228. RFC 1537       Common DNS Data File Configuration Errors    October 1993
  229.  
  230.  
  231.          *            MX 100  mailhost
  232.          pqr          MX 100  mailhost
  233.          *.pqr        MX 100  mailhost
  234.          abc.def      MX 100  mailhost
  235.          *.def        MX 100  mailhost
  236.          *.abc.def    MX 100  mailhost
  237.  
  238.    An overall wildcard MX record is almost never useful.
  239.  
  240.    In particular the zone file of a top level domain should NEVER
  241.    contain only an overall wildcard MX record (*.XX). The effect of such
  242.    a wildcard MX record can be that mail is unnecessarily sent across
  243.    possibly expensive links, only to fail at the destination or gateway
  244.    that the record points to. Top level domain zone files should
  245.    explicitly list at least all the officially registered primary
  246.    subdomains.
  247.  
  248.    Whereas overall wildcard MX records should be avoided, wildcard MX
  249.    records are acceptable as an explicit part of subdomain entries,
  250.    provided they are allowed under a given subdomain (to be determined
  251.    by the naming authority for that domain).
  252.  
  253.    Example:
  254.  
  255.          foo.xx.      MX 100  gateway.xx.
  256.                       MX 200  fallback.yy.
  257.          *.foo.xx.    MX 100  gateway.xx.
  258.                       MX 200  fallback.yy.
  259. 8. Hostnames
  260.  
  261.    People appear to sometimes look only at STD 11, RFC 822 to determine
  262.    whether a particular hostname is correct or not. Hostnames should
  263.    strictly conform to the syntax given in STD 13, RFC 1034 (page 11),
  264.    with *addresses* in addition conforming to RFC 822. As an example
  265.    take "c&w.blues" which is perfectly legal according to RFC 822, but
  266.    which can have quite surprising effects on particular systems, e.g.,
  267.    "telnet c&w.blues" on a Unix system.
  268.  
  269. 9. HINFO records
  270.  
  271.    There appears to be a common misunderstanding that one of the data
  272.    fields (usually the second field) in HINFO records is optional. A
  273.    recent scan of all reachable nameservers in only one country revealed
  274.    some 300 incomplete HINFO records. Specifying two data fields in a
  275.    HINFO record is mandatory (RFC 1033), but note that this does *not*
  276.    mean that HINFO records themselves are mandatory.
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Beertema                                                        [Page 5]
  283.  
  284. RFC 1537       Common DNS Data File Configuration Errors    October 1993
  285.  
  286.  
  287. 10. Safety measures and specialties
  288.  
  289.    Nameservers and resolvers aren't flawless. Bogus queries should be
  290.    kept from being forwarded to the root servers, since they'll only
  291.    lead to unnecessary intercontinental traffic. Known bogus queries
  292.    that can easily be dealt with locally are queries for 0 and broadcast
  293.    addresses.  To catch such queries, every nameserver should run
  294.    primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone
  295.    files need only contain a SOA and an NS record.
  296.  
  297.    Also each nameserver should run primary for 0.0.127.in-addr.arpa;
  298.    that zone file should contain a SOA and NS record and an entry:
  299.  
  300.          1    PTR     localhost.
  301.  
  302.    There has been extensive discussion about whether or not to append
  303.    the local domain to it. The conclusion was that "localhost." would be
  304.    the best solution; reasons given were:
  305.  
  306.    - "localhost" itself is used and expected to work on some systems.
  307.  
  308.    - translating 127.0.0.1 into "localhost.my_domain" can cause some
  309.      software to connect to itself using the loopback interface when
  310.      it didn't want to.
  311.  
  312.    Note that all domains that contain hosts should have a "localhost" A
  313.    record in them.
  314.  
  315.    People maintaining zone files with the Serial number given in dotted
  316.    decimal notation (e.g., when SCCS is used to maintain the files)
  317.    should beware of a bug in all BIND versions: if the serial number is
  318.    in Release.Version (dotted decimal) notation, then it is virtually
  319.    impossible to change to a higher release: because of the wrong way
  320.    that notation is turned into an integer, it results in a serial
  321.    number that is LOWER than that of the former release.
  322.  
  323.    For this reason and because the Serial is an (unsigned) integer
  324.    according to STD 13, RFC 1035, it is recommended not to use the
  325.    dotted decimal notation. A recommended notation is to use the date
  326.    (yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is
  327.    or can be more than one change per day in a zone file.
  328.  
  329.    Very old versions of DNS resolver code have a bug that causes queries
  330.    for A records with domain names like "192.16.184.3" to go out. This
  331.    happens when users type in IP addresses and the resolver code does
  332.    not catch this case before sending out a DNS query. This problem has
  333.    been fixed in all resolver implementations known to us but if it
  334.    still pops up it is very serious because all those queries will go to
  335.  
  336.  
  337.  
  338. Beertema                                                        [Page 6]
  339.  
  340. RFC 1537       Common DNS Data File Configuration Errors    October 1993
  341.  
  342.  
  343.    the root servers looking for top level domains like "3" etc. It is
  344.    strongly recommended to install the latest (publicly) available BIND
  345.    version plus all available patches to get rid of these and other
  346.    problems.
  347.  
  348.    Running secondary nameserver off another secondary nameserver is
  349.    possible, but not recommended unless really necessary: there are
  350.    known cases where it has led to problems like bogus TTL values. This
  351.    can be caused by older or flawed implementations, but secondary
  352.    nameservers in principle should always transfer their zones from the
  353.    official primary nameserver.
  354.  
  355. 11. Some general points
  356.  
  357.    The Domain Name System and nameserver are purely technical tools, not
  358.    meant in any way to exert control or impose politics. The function of
  359.    a naming authority is that of a clearing house. Anyone registering a
  360.    subdomain under a particular (top level) domain becomes naming
  361.    authority and therewith the sole responsible for that subdomain.
  362.    Requests to enter MX or NS records concerning such a subdomain
  363.    therefore always MUST be honored by the registrar of the next higher
  364.    domain.
  365.  
  366.    Examples of practices that are not allowed are:
  367.  
  368.       - imposing specific mail routing (MX records) when registering
  369.         a subdomain.
  370.  
  371.       - making registration of a subdomain dependent on to the use of
  372.         certain networks or services.
  373.  
  374.       - using TXT records as a means of (free) commercial advertising.
  375.  
  376.    In the latter case a network service provider could decide to cut off
  377.    a particular site until the offending TXT records have been removed
  378.    from the site's zone file.
  379.  
  380.    Of course there are obvious cases where a naming authority can refuse
  381.    to register a particular subdomain and can require a proposed name to
  382.    be changed in order to get it registered (think of DEC trying to
  383.    register a domain IBM.XX).
  384.  
  385.    There are also cases were one has to probe the authority of the
  386.    person: sending in the application - not every systems manager should
  387.    be able to register a domain name for a whole university.  The naming
  388.    authority can impose certain extra rules as long as they don't
  389.    violate or conflict with the rights and interest of the registrars of
  390.    subdomains; a top level domain registrar may e.g., require that there
  391.  
  392.  
  393.  
  394. Beertema                                                        [Page 7]
  395.  
  396. RFC 1537       Common DNS Data File Configuration Errors    October 1993
  397.  
  398.  
  399.    be primary subdomain "ac" and "co" only and that subdomains be
  400.    registered under those primary subdomains.
  401.  
  402.    The naming authority can also interfere in exceptional cases like the
  403.    one mentioned in point 4, e.g., by temporarily removing a domain's
  404.    entry from the nameserver zone files; this of course should be done
  405.    only with extreme care and only as a last resort.
  406.  
  407.    When adding NS records for subdomains, top level domain nameserver
  408.    managers should realize that the people setting up the nameserver for
  409.    a subdomain often are rather inexperienced and can make mistakes that
  410.    can easily lead to the subdomain becoming completely unreachable or
  411.    that can cause unnecessary DNS traffic (see point 1). It is therefore
  412.    highly recommended that, prior to entering such an NS record, the
  413.    (top level) nameserver manager does a couple of sanity checks on the
  414.    new nameserver (SOA record and timers OK?, MX records present where
  415.    needed? No obvious errors made? Listed secondary servers
  416.    operational?). Things that cannot be caught though by such checks
  417.    are:
  418.  
  419.       - resolvers set up to use external hosts as nameservers
  420.  
  421.       - nameservers set up to use external hosts as forwarders
  422.         without permission from those hosts.
  423.  
  424.    Care should also be taken when registering 2-letter subdomains.
  425.    Although this is allowed, an implication is that abbreviated
  426.    addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in
  427.    and under that subdomain.  When requested to register such a domain,
  428.    one should always notify the people of this consequence. As an
  429.    example take the name "cs", which is commonly used for Computer
  430.    Science departments: it is also the name of the top level domain for
  431.    Czecho-Slovakia, so within the domain cs.foo.bar the user@host.cs is
  432.    ambiguous in that in can denote both a user on the host
  433.    host.cs.foo.bar and a user on the host "host" in Czecho-Slovakia.
  434.    (This example does not take into account the recent political changes
  435.    in the mentioned country).
  436.  
  437. References
  438.  
  439.    [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
  440.        RFC 1034, USC/Information Sciences Institute, November 1987.
  441.  
  442.    [2] Mockapetris, P., "Domain Names Implementation and Specification",
  443.        STD 13, RFC 1035, USC/Information Sciences Institute, November
  444.        1987.
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Beertema                                                        [Page 8]
  451.  
  452. RFC 1537       Common DNS Data File Configuration Errors    October 1993
  453.  
  454.  
  455.    [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
  456.        974, CSNET CIC BBN, January 1986.
  457.  
  458.    [4] Gavron, E., "A Security Problem and Proposed Correction With
  459.        Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
  460.        October 1993.
  461.  
  462.    [5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
  463.        "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
  464.        USC/Information Sciences Institute, USC, October 1993.
  465.  
  466. Security Considerations
  467.  
  468.    Security issues are not discussed in this memo.
  469.  
  470. Author's Address
  471.  
  472.    Piet Beertema
  473.    CWI
  474.    Kruislaan 413
  475.    NL-1098 SJ Amsterdam
  476.    The Netherlands
  477.  
  478.    Phone: +31 20 592 4112
  479.    FAX:   +31 20 592 4199
  480.    EMail: Piet.Beertema@cwi.nl
  481.  
  482.  
  483. Editor's Address
  484.  
  485.    Anant Kumar
  486.    USC Information Sciences Institute
  487.    4676 Admiralty Way
  488.    Marina Del Rey CA 90292-6695
  489.  
  490.    Phone:(310) 822-1511
  491.    FAX:  (310) 823-6741
  492.    EMail: anant@isi.edu
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Beertema                                                        [Page 9]
  507.  
  508.